M2M Service Layer
From a protocol stack perspective, service layers are typically layered on top of application protocol layer and provide value added services to client applications. Hence service layers are often categorized as ‘middleware’ services. For example, FIG. 1 shows an exemplary service layer 101 in between an IP networking stack 102 and applications 103.
An example deployment scenario of a service layer instances within a network is shown in FIG. 2. In FIG. 2, the service layer instances 105 are shown deployed on various network nodes (gateways and servers) and providing value-added services to network applications found in network application domain 106, device applications found in device application domain 107, as well as to the network nodes found in network services domain 108, for example. Service layer instance 105 is a realization of a service layer.
An M2M/IoT service layer is an example of one type of service layer specifically targeted towards providing value-added services for M2M/IoT type devices and applications. Industry standards bodies (e.g. oneM2M-oneM2M Functional Architecture, oneM2M-TS-0001 oneM2M Functional Architecture-V-2.1.0) has been developing M2M/IoT service layers to address the challenges associated with integration of M2M/IoT types of devices and applications into deployments such as the Internet/Web, cellular, enterprise, and home network. An M2M service layer can provide applications and devices access to a collection of M2M centric capabilities supported by the service layer. A few examples include security, charging, data management, device management, discovery, provisioning, and connectivity management. These capabilities are made available to applications via APIs which make use of message formats, resource structures and resource representations defined by the M2M service layer.
oneM2M develops technical specifications that address the need for a common M2M Service Layer that can be readily embedded within various hardware and software, and relied upon to connect a wide variety of devices in the field with M2M application servers worldwide.
The oneM2M common services layer supports a set of Common Service Functions (CSFs) (e.g., service capabilities), as shown in FIG. 3. An instantiation of a set of one or more particular types of CSFs is referred to as a common services entity (CSE) (e.g., CSE 111), which can be hosted on different types of network nodes (e.g., infrastructure node, middle node, application-specific node).
oneM2M is developing the service layer in two architectural approaches, called resource oriented architecture (RoA), e.g., FIG. 4, and service oriented architecture (SoA), e.g., FIG. 5. According to the oneM2M RoA RESTful architecture, CSFs are represented as a set of “resources.” A resource is a uniquely addressable element in the architecture having a representation that can be manipulated via RESTful methods such as Create, Retrieve, Update, and Delete (CRUD). These resources are made addressable using universal resource identifiers (URIs). A resource may contain child resource(s) and attribute(s). A child resource is a resource that has a containment relationship with a parent resource. The parent resource representation contains references to its child resources(s). The lifetime of a child-resource is limited by the parent's resource lifetime. Each resource supports a set of “attributes” that store information of the resource.
The SoA architecture is being developed to consider legacy deployment that is not RESTful based. It re-uses largely the same service layer architecture as shown in FIG. 5. The service layer contains various M2M services, and multiple services can be grouped into service components. In addition to existing reference points, it introduced the inter-service reference point Msc. Communication between M2M service components which pass over the Msc reference point utilizes a web services approach, e.g., web services message exchange patterns (MEP).
Group Management in oneM2M
There is a group management (GMG) CSF in oneM2M which is responsible for handling group related operations. GMG may handle the following operations:                Request to create, retrieve, update, and delete a group and the associated group members.        Create one or more groups in CSEs in the nodes in oneM2M system for a particular purpose (e.g., facilitation of access control, device management, fan-out common operations to a group of devices, etc.).        Manage group membership and handle requests to add or remove members to and from a group's member list.        Leverage the capabilities of other CSFs in order to fulfill the functionalities supported by the GMG CSF service functions. Examples include: Security CSF for authentication and authorization.        Forward requests to all members in the group. In case the group contains another group as a member, the forwarding process is done recursively. GMG CSF generates an aggregated response by aggregating the corresponding responses from the Group members.        Support subscriptions to individual groups.        Leverage the existing capabilities of the Underlying Network including broadcasting/multicasting.        
FIG. 6 illustrates the <group> resource defined by oneM2M for group management. The virtual resource <fanOutPoint> is defined to deliver the specific request to each of the group members. FIG. 7 is an exemplary method flow for a <group> resource. FIG. 8 illustrates an exemplary method flow for a <fanOutPoint> resource.